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Anchor Section and event value. Several methods exist for storing these values, and it 
would be apparent to one skilled in the art that the exact method chosen will depend 
on other implementation and design choices. For instance, any of the following 
methods may be implemented: (a) storing each value- Anchored Linear Event 
5 combination in a different table record, (b) storing each value-Anchor Section 

combination in a different table record with a Blob (binary large object) column that 
contains the offset information for the Anchored Linear Event(s), (c) storing all event 
values (for a specific event type) for each Anchor Section in a different record with a 
Blob column that contains the value that applies to each Anchored Linear Event, and 
1 0 (d) storing each Value- Anchored Linear Event combination in a different table record 
with the same Anchored Linear Events being used for all TIS event data (i.e., dynamic 
segmentation). 

[0075] Saving a new event value can result in complicated updates to the 

current TIS database (see Figure 1). For example, referring to Figure 8, suppose the 

15 pavement type currently has value X 81 along an entire Anchor Section 71, and a new 
value Y 82 is entered from offset 30% to offset 50%. Then the new value is X from 
offset 0% to 30% (reference 83), Y from offset 30% to 50% (reference 84), and X 
from offset 50% to 100% (reference 85). Using Method (a), above, this would be 
stored in three (3) event table rows, one for each Anchored Linear Event. Using 

20 Method (b), this would be stored in two (2) event table rows, one for each event value. 
Using Method (c), this would be stored in one (1) event table row. The number of 
rows required using Method (d) would depend on the current segmentation for the 
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given Anchor Section, and it is possible that event tables for every event associated 
with this Anchor Section would require updating. 

[0076] The method used to store the event values has a significant impact on 

the use of queries to access the TIS data. Methods (a), (b), and (d) support simple 

5 queries based on a single event attribute. (Method (c) does not because the event 
value is "hidden" inside the Blob.) Only Method (d) supports simple queries for 
multiple event attributes; the other methods require implementing some program logic 
to calculate the intersection and/or union of the Anchored Linear Events associated to 
the event values of interest. 

10 [0077] Many ofthe reports required ofthe TIS data by GDOT are summaries 

of event data by jurisdictional area (e.g., county, congressional district). TIS provides 
two methods of accessing event data by jurisdictional area, both of which are depicted 
in Figure 10. 

[0078] Referring now to Figure 10, jurisdictional area polygons 1000 are 

15 maintained as spatial TIS data 1 00 1 . The user can also create temporary, ad hoc 

spatial jurisdictional areas for use in querying the TIS data. Event data 1010 for such 
areas will be accessed by (1) using a spatial query 1002 to identify the Anchor 
Sections contained within the specified jurisdictional area 1003, (2) using a relational 
query 1004 to compile the event data for those Anchor Sections 1005, and (3) using a 
20 report or summary query 1006 to summarize the Anchor Section event data 1007. 
[0079] Event tables are used to store the Anchor Sections associated with the 

most important jurisdictional areas. These event tables facilitate processing by storing 
23 
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the pre-processed result of the spatial query in step 1 above. Event data 1010 for such 
areas are accessed by applying steps 2 and 3 from above to the stored Anchor Sections 
for the jurisdictional area. 

[0080] Modifications of existing Arclnfo applications are used to maintain the 

5 jurisdictional data, which will be exported to the TIS database as part of Arclnfo data 
publication. 

[0081] In addition to TIS data tied directly to the road network and 

jurisdictional areas, TIS maintains links to other data that include a spatial component. 
For example, bridge information management system (BIMS, as implemented in the 
10 GDOT system) software maintains information about bridges; TIS includes links to 
this information. In particular, TIS supports the following sorts of spatial links to 
other data: 

1 . Some data is associated with a location on the road network (e.g., a bridge 
"covers" a portion of a road), then TIS includes the following types of 

15 information: (a) a table that describes the object/information, how to link to 

the source data for this object, and includes spatial data for the object (i.e., a 
GIS layer) and (b) an event-like table that relates each bridge to the portion of 
roadway that it covers. The data is accessible both through (a) a GIS map 
interface, (b) spatial queries, and (c) relational Anchor Section based queries. 

20 2. Other data is not directly associated with a location on the road network (e.g., 

wetlands), in which case TIS includes a table that describes the 
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